Thank you for your PR.
I will review this in the following days.

I want to quickly talk about the Glossary. I have not looked at the code, so this is only a quick exchange of information.

The Glossary, unlike Timeline Text Events, does not fall back and that is intended by design. If there is no translation for the target locale, they won't do anything. This ensures no wrong Glossary is displayed between languages.

Let me know if this is what you encountered.

Not sure what I did different this time, it works on the old version.

Available translations of the timelines: en, it
Available translations of the glossaries: en, de

Testing locale: en

• Old: timeline: en, glossary: en
• New: timeline: en, glossary: en

Testing locale: it

• Old: timeline: it, glossary: en
• New: timeline: it, glossary: en

Testing locale: de

• Old: timeline: en, glossary: de
• New: timeline: en, glossary: de

Testing locale: fr

• Old: timeline: en, glossary: en
• New: timeline: en, glossary: en

So the behavior is still the same and it always used the fallback logic of godot.

There is still one issue in the old version and fixed in this PR:

• Use the original locale name of one glossary entry in a translation of another glossary entry.
• Run the game with the original locale.
• The text box highlights the correct words.
• The tooltip shows the wrong entry.

Bypassing the fallback logic of godot completely would be possible, but the new code would still need some sort of fallback. Otherwise the game would need to have the glossary in every single language+country+variant+... combination a player could have.

I am not sure if the large complexity of building our own fallback logic is really worth it. The only situation where it makes a difference is if timelines, but not glossary, are translated for a specific locale. And it would also be extremely difficult to test it because locales have so many corner cases.

I also made changes to some events to reduce the number of unused translation entries:

• The choice event no longer creates an unused translation entry for disabled_text if the choice can't be disabled.
  • It is still possible to use the fallback behavior in the main language but a different text in other languages. I am not sure how helpful this really is.
  • Alternative: Remove all empty disabled_text entries even if the choice can be disabled.
    • If a game doesn't use different disabled texts, this could reduce the number of entries even more.
    • This would also allow a generic implementation across all event types, if we want that.
• The label event no longer creates a translation entry for display_name if it is empty.
  • Or is there any situation where you would need a display name in some languages, but not in the main language?

Please let me know if you want to keep the old behavior or prefer something different.